Technical Note TN1202
Building QuickTime Components for Mac OS X

目次

この Technote では、Mac OS X で動作する CFM と Mach-O の QuickTime コンポーネントの作成方法について述べ、既存の QuickTime コンポーネントを移植するのに必要な事項を示します。

更新:2001年 3月 8日






バイナリーフォーマット

Mac OS X は、CFM と Mach-Oの2つのアプリケーション・バイナリーフォーマットをサポートします。CFM(Code Fragment Manager) は、以前の Mac OS が稼動する Power Macintosh で使われており、Metroweks CodeWarrior 等のコンパイラでサポートされています。Mach-O は Mac OS X のネイティブなオブジェクトフォーマットで、gcc がサポートしています。

Mac OS X 用の Carbon component は、CFM または Mach-O コードで作成します。


先頭に戻る

Carbon CFM Component

Mac OS X 用の CFM component は、Mac OS 7, 8, 9 用の物と似たメカニズムで構築しますが、以下の点が違います。

  1. Carbon CFM component では、 InterfaceLib や QuickTimeLib の代わりに CarbonLib をリンクします。
  2. Mac OS X はリソース中の component コードをサポートしないので、データフォークのファイル中に納める納める必要があります。リソースフォークには、実際のコードを指し示す、拡張された 'cfrg' リソースを持たせます。リスト1を参照して下さい。
  3. ’thng' リソースの "code resource type" 項目は、'cfrg' とします。"code resource ID" 項目は、実際のリソースIDではありません。'cfrg' リソースに1つの項目しかない場合、"code resource ID" はゼロとします。複数ある場合は、"code resource ID" に 'cfrg' の拡張されたメンバー (qualifier 1) に対応した値をセットします。リスト2を参照して下さい。
  4. コードの main entry point は、 routine descriptor でなく component dispatcher routine とします。Mac OS X の Carbon には routine descriptors は存在せず、UPP も routine descriptor へのポインタではありません。
  5. ”platform type” は platformPowerPC(= 2) ではなく、platformPowerPCNativeEntryPoint(= 5) とします。リスト2を参照して下さい。

先頭に戻る

複数の CFM Component を1つのファイルにマージする

'cfrg' リソースのIDは 0 でなくてはならず、1つのファイルに複数の 'cfrg' リソースを持つことはできません。'cfrg' リソースの終わりの部分は配列になっていて、それぞれの code fragment の name と architecture type を示しています。

CodeWarrior MacOS Merge Linker は、複数の Mac OS X 用 Carbon CFM Component を、1つのファイルに納めることができます。このリンカは拡張された code fragment 'cfrg' (0) を使った項目の配列を自動的に生成し、それぞれの code fragment をつなげます。マージされた 'cfrg' リソースには、正しい code fragment の location, offset, length が設定されます。

MacOS Merge は CodeWarrior の 'Target Settings' preference panel で指定できます。MacOS Merge 'Linker Settings' preference panel の 'Copy Code Fragments' と 'Copy Resources' option が選択されていることを確認して下さい。

'cfrg' リソースの詳細につきましては、ヘッダファイル CodeFragments.r と、Inside Macintosh PowerPC System Software の Code Fragment Manager の章を参照して下さい。

リスト 1 - CFM Custom 'cfrg' resource

// Extended versions of the 'cfrg' resource template.
#define cfrg_RezTemplateVersion 1

#include <CodeFragments.r>
// Custom extended code fragment resource
// CodeWarriorが MacOS Merge target をビルド時に
// code fragmentのoffsetとlengthを正しく設定します。
resource 'cfrg' (0) {
 {      
  extendedEntry {
    kPowerPCCFragArch,              // archType
    kIsCompleteCFrag,               // updateLevel
    kNoVersionNum,                  // currentVersion
    kNoVersionNum,                  // oldDefVersion
    kDefaultStackSize,              // appStackSize
    kNoAppSubFolder,                // appSubFolderID
    kImportLibraryCFrag,            // usage
    kDataForkCFragLocator,          // where
    kZeroOffset,                    // offset
    kCFragGoesToEOF,                // length
    "MyComponent",                  // member name
            
    // Start of extended info
            
    'cpnt',             // libKind
                        // (kFragComponentMgrComponent == 'comp' 
                        // ではありません)
    "¥0x01¥0x00",       // qualifier 1 - hex 0x0100 (256)
                        //               'thng'中の対応するCode ID
    "",                 // qualifier 2
    "",                 // qualifier 3
    "My CFM Component", // intlName, localized
  };
 };
};


リスト 2 - CFM 'thng' resource

// extended 'thng' template
#define thng_RezTemplateVersion 1

#include <Components.r>
resource 'thng' (256) {
    kAQTComponentType,      // Type         
    'DEMO',                 // SubType
    'demo',                 // Manufacturer
    0,                      // not used
                            // - use componentHasMultiplePlatforms
    0,
    0,
    0,
    'STR ',                 // Name Type
    128,                    // Name ID
    'STR ',                 // Info Type
    129,                    // Info ID
    0,                      // Icon Type
    0,                      // Icon ID
    kMyComponentVersion,    // Version
    componentHasMultiplePlatforms + // Registration Flags 
    myComponentRegistrationFlags,
    0,                      // Icon FamilyのResource ID
    {
      kMyComponentFlags,    // Component Flags                      
      'cfrg',               // Special Case: data-fork
                            // based code fragment
      /* CFM componentでのCode IDの使い方:
       0 (kCFragResourceID) - 先頭のCode fragment。
        1ファイルに一つのcarbon componentがある時のみ。
        custom 'cfrg' resourceは必要無いので、
        kCFragResourceIDを使うとわかりやすい。
       n - この値はcustom 'cfrg' resourceのspecial 'cpnt'
        extension field (qualifier 1)に対応させる。
        */
      256,                  // Custom code ID
      platformPowerPCNativeEntryPoint,
                            // Platform Type
                            // (gestaltComponentPlatform の返値。
                            // これがエラーのときはgestaltSysArchitecture)
    };
};



先頭に戻る

Mach-O Component

Mac OS X 用の Mach-O component は、データフォークに dynamic library (dylib) を持ち、Mac OS 7, 8, 9と似たメカニズムを使ってビルドされますが、以下の点が以下の点が異なります。

Mach-O components for Mac OS X contain a dynamic library (dylib) in their data fork and are built using similar mechanisms to those for Mac OS 7, 8 and 9 with the following differences:

  1. Windows と同様に、エントリーポイントはシンボルネームによって検索されます。"code resource type" は 'dlle' で、'dlle' リソースは export されたシンボルネームをC言語文字列 で持ちます。リスト3を参照して下さい。
  2. platform type は Carbon CFM component と同様に、platformPowerPC でなく、platformPowerPCNativeEntryPoint とします。リスト4を参照して下さい。

Project Builder では、Mac OS X用の単独ファイルと bundled component の双方が作れます。

bundled component をビルドするには、Project Builder の 'New Project' ダイアログで 'Carbon Bundle' を選ぶか、既存のプロジェクトに追加する場合は 'New Target' ダイアログで 'Bundle' を指定します。

単独ファイルの component をビルドするには、Project Builder の 'New Project' ダイアログから 'Empty Project' を選び、'Library' target を追加して、 targets build setting を 'LIBRARY_STYLE' から 'DYNAMIC' に変更して下さい。

リスト 3 - Mach-O Entry Point

// Code Entry Point for Mach-O and Windows
resource 'dlle' (512) {
    "MyComponentDispatch"
};


リスト 4 - Mach-O 'thng' Resource

// extended 'thng' template
#define thng_RezTemplateVersion 1

#include <Components.r>
resource 'thng' (256) {
    kAQTComponentType, // Type         
    'DEMO',      // SubType
    'demo',      // Manufacturer
    0,           // 未使用
                 // - componentHasMultiplePlatformsを使用
    0,
    0,
    0,
    'STR ',      // Name Type
    128,         // Name ID
    'STR ',      // Info Type
    129,         // Info ID
    0,           // Icon Type
    0,           // Icon ID
    kMyComponentVersion,  // Version
    componentHasMultiplePlatforms + // Registration Flags 
    myComponentRegistrationFlags,
    0,           // Resource ID of Icon Family
    {
      kMyComponentFlags, 
      'dlle',    // Code Resource type - Entry point found by 
                 // symbol name 'dlle' resource
      512,       // ID of 'dlle' resource
      platformPowerPCNativeEntryPoint,
                 // Platform Type
                 // (gestaltComponentPlatform の返値。
                 // これがエラーのときはgestaltSysArchitecture)
    };
};



先頭に戻る

File Extension と 格納場所

どちらの component のファイル名も ".component" の拡張子を付け、 /Library/QuickTime ディレクトリに置きます。


先頭に戻る

Carbon と Mac OS 8 / 9 Component

Mac OS 8 と 9 上の CarbonLib はアプリケーション(とアプリケーション・プラグイン)のみをサポートし、component はサポートしません。よって Mac OS 8 と 9 用には、InterfaceLib をリンクした物を別途配付する必要があります。

しかしながら、Mac OS X で稼動する CarbonLib をリンクした component の Carbon バージョンと、Mac OS 8 / 9 で稼動する InterfaceLib をリンクしたバージョンは、一つのファイルに納めることができます。

platform codes がプラットフォームを指し示し、platformPowerPCNativeEntryPoint であれば Carbon バージョンの、platformPowerPC であれば非 Carbon バージョンのコードを正しくロードします。


先頭に戻る

サンプルコード

Electric Image Component Sample - このサンプルは、このドキュメントの記述概要のデモで、Graphics Importer, Movie Importer, Image Decompressor の3つの QuickTime component のビルドの方法を示します。3つの component が一緒になって、Electric Image 形式の画像ファイルを QuickTime で扱える様にします。ここから入手できます。

先頭に戻る


参考文献

'cfrg' リソースの詳細につきましては、ヘッダファイル CodeFragments.r と、Inside Macintosh PowerPC System SoftwareCode Fragment Manager の章を参照して下さい。


先頭に戻る